内存溢出(内存溢出找不到原因)

1. 内存溢出，内存溢出找不到原因？

溢出是VB（Visual Basic）程序开发中常见的一个错误。当数据的大小超过存储器所能容纳的最大值时，就会发生溢出错误。由于数据量太大而无法存入内存，因此溢出错误发生时，程序将出现异常行为，或者在执行特定操作时崩溃。

溢出问题通常发生在尝试存储超出所允许的范围的数据时，例如，在尝试存储一个大于255的十进制数时，就会发生溢出错误，因为8位字节只能存储最大值为255的数据。

内存溢出(内存溢出找不到原因)

2. VB中编译错误内存溢出是什么意思？

缓冲区溢出是指程序的缓冲区无限制的使用导致数据超出范围覆盖了其他程序的代码、数据等内容，如果被覆盖的内容是系统数据或代码就会导致系统崩溃

3. javaexcelpoi大数据量50W内存溢出？

Workbook workbook = new SXSSFWorkbook(1000); poi有个机制每次往内存中写1000条数据，这个1000你可以改的尽量别大于10000条数据，写完1000条数据后再重新写，这样就不会内存溢出了。

4. 饥荒内存溢出怎么办？

是不是特效、画质、分辨率开得过高高于你的电脑配置所能达到得了？建议降低这些参数。同时推荐下一个N2O游戏大师，实时监控内存占用情况，这软件可以自动释放内存，应该能有所帮助。

5. VBA数组内存溢出？

上面定义那儿改下:dim arr as long或者dim arr(2000000) as long我试过到千万级都不会溢出的,上了亿就会溢出.

6. 玩cf内存溢出？

32位的win7，只能寻址3.25－3.5g的内存。无法利用好4G内存，最好换64位系统。32位 WIN7解决龙之谷out of memory(Physical)内存溢出的方法：

1、打开开始菜单，在搜索栏里面输入CMD，在查找到结果中找到CMD.exe，按右键以管理员身份运行。

2、在弹出的黑色命令框中输入：bcdedit /set increaseuserva 30723、提示成功后重启电脑。4、若对其他游戏产生副作用，可以输入恢复指令：bcdedit /deletevalue increaseuserva 这是2G内存的。4G内存，可以试一下把3072改成6144 。

7. Java程序员是如何解决内存溢出问题的？

题主说的这个问题，应该是击中了众多java开发者的心，内存溢出确实是每个开发人员需要面对的问题，在这些我总结了一些经验，希望能帮到你。

写在前面

java程序的性能问题定位，一直都是开发者需要面对的一个“拦路虎”，在前面的两篇文章中，已经介绍了Heap dump的概念和生成方式，以及Shallow heap和Retained heap以及GC ROOT的概念，本篇文章，我们继续来介绍一些新的概念和基于一个dump案例，详尽的介绍，在程序OOM后，改如何去定位具体原因。

再次提及dominator tree（支配树）

如果你玩过竞技类游戏，肯定会很熟悉Dominating -主宰比赛这个单词。

在Memory Analyzer工具中提供了对象图的支配树。将对象引用图转换为dominator tree可以让轻松地确定Retained heap最大内存块和对象之间保持活动的依赖关系，相当于主宰了整个JVM的感觉。

我们把java对象之间的引用关系看做一张有向图，如果所有指向Y的对象路径都要经过X，则我们说X支配Y。如果X是离对象Y最近的支配对象，则我们说对象X是Y的直接支配者( immediate dominator)。

再强化记忆一下，X对象要直接支配Y，必须满足这两点：

指向Y的对象路径都要经过X。X对象是离Y最近的支配对象。

左边是对象的引用图，右边是支配树。

C节点的子树就是所有被C支配的节点的集合，也称为C的Retained Set。

由图可以看出，C是E的直接支配节点，所以C的上级支配节点B也可以支配E。

dump分析初步

首先用MemoryAnalyzer工具打开dump文件。

从整体情况可以看出，1.6 gb的堆内存，有大对象占了1.1g。

怀疑是有内存泄漏，我们通过Leak Suspect Report报告查看

内存泄漏分析报告显示有两项问题：

一是WebappClassLoader 类加载器装载的A.A[][] 对象占了约1.2g（70.40%）。二是一个名为TP-Processor9的线程持有本地变量多达337M（占了19.58%）。

通过分析报告，我们初步可以推断出OOM的问题应该出在这两个地方，我们逐个击破。

内存泄漏点一

先来看类装载器加载的AA对象。我们点开内存泄漏报告的Detail，查看其详情。

Shortest Paths To the Accumulation Point视图可以看出正是和org.apache.catalina.loader.WebappClassLoader这个GC root相连导致当前Retained Heap占用相当大的对象无法被回收，而对象数量居然达到了170288个。

Accumulated Objects in Dominator Tree视图，可以看出AA对象中，到底是什么内嵌对象占用heap高。

可以看出，170288个AA对象数组内部，主要是AH对象和 AM对象。

我们继续向下看，通过按class类分组，来看看具体占用比例情况。

按class分组后，冒出了一个Af对象，反倒AH占用不是那么多了。

小结：AH/AM/Af三个对象占用堆内存很高，并且它们的gc root是WebappClassLoader。

内存泄漏点二

TP-Processor9 线程本身就是GC root，故只有一条数据。

以这个线程为GC ROOT来看看，它的支配树是什么样的？

可以看到19.58%的Retained Heap就是来源于TP-Processor9 线程本身。这意味着，如果这个线程能被gc回收掉，则至少能释放19.58%的堆内存。

以TP-Processor9 线程为gc root的支配树，按class分类，可以发现Am对象本身占用163m左右。

Detail明细的最后由于当前怀疑泄露点为TP-Processor9 线程对象，故展示了线程明细信息，调用栈信息。

小结：TP-Processor9 线程内部可能导致内存泄漏。